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Abstract. As agent systems grow larger and more complex, there is an 
increasing need to formally verify them. Furthermore, it is often sug¬ 
gested that complex systems can be regulated using organizational mod¬ 
els, imposing constraints on the agents in the systems. Agents that can 
understand the organizational model and constraints in a system is said 
to be organization-aware. This paper is concerned with verification of 
organization-aware agents. We show how agents using AORTA, a frame¬ 
work for making agents organization-aware, can be formally verified us¬ 
ing an extended version of the Agent Java PathFinder (AJPF), a model 
checking system designed specifically for agent programming languages. 
We integrate AORTA with the Agent Infrastructure Layer (AIL), which 
is an intermediate layer on top of which APLs can be implemented, and 
use our extension of AJPF to verily a system of agents aiming to write 
a paper together by using an organization for coordination. 

Keywords: Model Checking, Agent Programming Languages, Organi¬ 
zational Reasoning, Organization-Aware Agents 


1 Introduction 

In many of the areas where multi-agent systems (MASs) are used, there is a need 
for dependability and security. Therefore, it is increasingly necessary to consider 
formal verification of such systems [4]. Furthermore, we have seen an increase of 
interest in the area of organization-oriented MAS, i.e. systems in which agents 
have to consider organizational constraints. The motivation for organizational 
MASs is the increasing complexity of heterogeneous agents in open systems. The 
owner of an open system cannot in general assume much about agents entering 
the system, and it is therefore important to be able to regulate their behavior 
to ensure that it is within the acceptable boundaries of the system. 

Organizational models (e.g. A4oise+ [TB]) are designed to describe what is 
expected of agents in the system without taking the individual agents and their 
implementation into account. This is done using the notion of roles: an agent 
can a enact roles, giving it certain responsibilities (the objectives of the role) 
while providing certain capabilities (access to objects in the system, access to 
groups of other agents, etc.). Furthermore, organizational models often have a 
normative aspect: behavior, or states of affair, that is expected of the agents in 
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the system, but is not directly enforced. That is, the agents are free to violate the 
norms of a system, but they should then expect to be punished. Organizational 
models thus provide a way for the designer of a system to explain to the agents 
entering the system, what is expected of them. 

However, if agents are expected to fulfill the system’s expectations of them, 
they need a way to understand the organizational model of that system. Agents 
that are able to do this are organization-aware [3]. Organization-aware agents 
will naturally tend to be more complex than their “unaware” counterparts; even 
though programming them may be easier, since certain aspects may be auto¬ 
mated (task allocation, coordination, etc.), the reasoning cycle of the agents will 
include more steps. This makes it even harder to convince ourselves that our 
implementation is correct. 

Since agent-oriented programming (AOP) differs from the well-known object- 
oriented programming (OOP), the verification techniques from OOP must be 
extended to capture the agent metaphor. That is, since agents are autonomous 
and their behavior is based on beliefs and intentions, we need to be able to not 
only check what the agent does (similar to verification in OOP), but also why it 
did so. 

The principles of model checking as defined in [2] ‘Hs an automated technique 
that, given a finite-state model of a system and a formal property, systematically 
checks whether this property holds for (a given state in) that modeF. Model 
checking agent programming languages (APLs) can thus be reduced to translat¬ 
ing the system into a finite-state model in which we can prove certain properties. 
Since agents are usually enriched with mental attitudes such as beliefs, goals and 
intentions, model checking APLs is only interesting, if we can verify properties 
about these mental attitudes. For example, it is possible to check whether agents 
in a system only intend to achieve goal states by checking the temporal formula 
0(l{ag,cj)) — G{ag,cj))). Here, ag refers to an agent, </> is a state and I and G 
are modal operators referring to intentions and goals, respectively. Quite some 
work has been done to make it possible to perform model checking on existing 
APLs, and for example, the Agent Java PathFinder project m is an example 
of a practical system in which model checking is feasible. 

In this paper, we present an extension to AJPF, which makes it possible to 
perform verification of organization-aware agents. We use AORTA [TH] to make 
agents organization-aware, and extend the specification language to incorporate 
modalities about organizational information. Our contribution is two-fold: first, 
we integrate AORTA with the Agent Infrastructure Layer (AIL), which is an 
intermediate layer on top of which APLs can be implemented. By integrating 
AORTA with AIL, we enable verification of organization-aware agents from po¬ 
tentially any APL with a clear semantics. Second, we use the integration to verify 
properties in a system of agents working together to write a scientific paper. 

The rest of the paper is organized as follows. First, we provide a brief de¬ 
scription of the AORTA framework in section [21 We then describe the AJPF 
system, which is used to translate MASs into hnite-state models on which model 
checking can be done (section|3]). In sectionjUwe present our extension to AJPF, 
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making it possible to perform model checking on organization-aware agents. We 
evaluate the system in section [5] and we conclude the paper in section [SI 

2 The AORTA framework 

AORTA [18] is an organizational reasoning component that can be integrated into 
an agent’s reasoning mechanism, allowing it to reason about (and act upon) reg¬ 
ulations specified by an organizational model using reasoning rules. That is, the 
organization is preexisting and independent from the agent and the component 
is agent-centered, focusing on letting the agent reason about the organization. 
By separating the organization from the agent, the architecture of the agent is 
independent from the organizational model, and the agent is free to decide on 
how to use AORTA in its reasoning. The separation is achieved by basing the 
component on reasoning rules using an organizational metamodel, designed to 
support different organizational models. A prototype of AORTA has been imple¬ 
mented in JavrQ [19], designed such that it can provide organizational reasoning 
capabilities to agents implemented in existing APLs. 

In this paper, we use an extended version of the AORTA architecture de¬ 
scribed in [19] : options are generated automatically, action deliberation and 
coordination are merged into a single phase, and we incorporate obligations. 
Organizational reasoning in AORTA is then divided into three phases: obligation 
check (OC), option generation (OG) and action execution (AE). The OC-phase 
uses the agent’s mental state and organizational state to determine if obligations 
are activated, satisfied or violated, and updates the organizational state accord¬ 
ingly. The OG-phase uses the organizational specification to generate possible 
organizational options. The agent considers these options in the AE-phase using 
reasoning rules, which can alter the organizational state and the agent’s inten¬ 
tions, or send messages to other agents. The component is shown in figure |TJ 
We assume is connected to a cognitive agent, i.e., agents with mental attitudes 
(such as beliefs and goals) and practical reasoning rules. 

Checking obligations: In the OG-phase, AORTA uses the agent’s state to deter¬ 
mine for each obligation if it should change to a new state. We use conditional 
obligations with a deadline, so an obligation can change state in several different 
situations. If the condition for activating an obligation has happened, the com¬ 
ponent activates the obligation by updating the organizational state. Similarly, 
it checks whether the obligation has been satisfied (the objective is completed) 
or violated (the deadline was reached before the objective was completed). 

Option generation: In the OG-phase, AORTA uses the mental state of the agent 
and the organizational state to consider what the agent can do regarding the 
organization. The following organizational aspects are considered in the OG- 
phase: 

^ Java was chosen since many existing agent platforms are built in Java. 
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AORTA 


Cognitive Agent 


Organizational beliefs 


OC 


OG 


Beliefs 


AE 
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Reasoning rules 


Mailbox 


Fig. 1. The AORTA component. The arrows indicate flow of information. Obligations 
and options are generated from the organizational beliefs, and actions are based on the 
generated options. 


Role enactment: Roles that are possible to enact given the agent’s goals. 
Role deactment: (Currently enacting) roles that have been fulfilled or are no 
longer useful. 

Obligations: States the agent is currently obliged to achieve. 

Delegation: Objectives that can be delegated based on a dependency relation. 
Information: Obtained information that other agents will benefit from know¬ 
ing. 

The options that are generated in this phase are then available to act upon in 
the AE-phase. 

Action execution: The AE-phase uses reasoning rules to decide how to react on 
a given option in a given context. The AE-phase selects at most one option to 
act upon. The reasoning is based on rules of the fornjl 

option : context —>■ action 

where option is a previously generated option, context is a state description 
that should hold for an action to be applicable, and action is the action to be 
executed. 

The agent has actions available to enact or deact a role, commit to complete 
or drop an objective, and send messages. This corresponds to the options that 
can be generated in the previous phase. 

2.1 The AORTA organizational metamodel 

Reasoning in AORTA uses an organizational metamodel, which is based on roles, 
objectives and obligations, as these concepts are commonly used in existing 
organizational models (e.g. AfoiSE+). 

^ Inspired by the plan syntax of AgentSpeak(L) |2U| . 
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Definition 1 (Organizational metamodel). The organizational metamodel 
of AORTA is defined by the following predicates: 


ro\e(Role, Objs) 
ohj (Obj, SubObjs) 
dep(Rolei, Role2, Obj) 
res(Ag, Role) 


Role is the role name, and Objs is a set of 
objeetives. 

Obj is the name of an objective, and SubObjs is a 
set of sub-objeetives. 

Role Rolei depends on role Role2 for eompletion 
of objective Obj. 

Agent Ag enacts role Role. 


cond (Role, Obj, Deadline, Cond) A conditional obligation for role Role to complete 

Obj before Deadline when Cond holds. 


(Ao\(Ag, Role, Obj, Deadline) An obligation for agent Ag playing role Role to 

complete Obj before Deadline. 


\i\o\(Ag, Role, Obj) 


Agent Ag playing role Role has violated the obli¬ 
gation to complete Obj. 


A role is defined only by its name and its main objectives. Sub-objectives of 
an objective are specified using obj-predicates. We distinguish between the differ¬ 
ent states of obligations by using different predicates. For example, a conditional 
obligation is represented by the predicate cond (borrower, return{Book), Dead¬ 
line, borrowed{Book)). If an agent Bob enacts the borrower role and borrows 
the book “1984”, the obligation is activated, which is represented by the predi¬ 
cate oh\{bob, borrower, return{1984 ), Deadline). A violation of the obligation is 
represented by the predicate viol(6o6, borrower, return{1984)). 


2.2 Operational semantics of AORTA 

The AORTA framework has a well-defined operational semantics, which has been 
implemented in Java and integrated with Jason. We will not go into details 
with the semantics in this paper, but give the relevant definitions required to 
understand our integration of AORTA with AIL. 

One of the key ideas of AORTA is the notion of the organizational knowledge 
base used by the component for reasoning about options and actions. Further¬ 
more, the component contains an options base containing the options generated 
in the OG-phase. 

Definition 2 (Mental state). The AORTA mental state is based on knowledge 
bases. Each knowledge base is based on a predicate language, L, with typical 
formula f. The agent’s belief base and intention base are denoted Sa and Ta, 
respectively. The language of the organization is denoted L®”®, and L°’'^ C L, 
and the option language is denoted , and L°p* C L. The organizational 
specification and options are denoted Do and To, respectively. The mental state, 
MS, is then a tuple of knowledge bases: 

MS= {Ea,ra,Eo,ro), 
where Ea,ra C L, So C and To C L°p* 
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Definition 3 (Options). The option language, with typical element 7 is 
defined as follows: 


7 role(i?) | obj(O) | send(i?, ilf, (/>), 

where R is a role identifer, O is an objeetive, ilf is tell or achieve, and (f> G L is 
a message. 

Each of the knowledge bases in the mental state can be queried using rea¬ 
soning formulas. 

Definition 4 (Formulas). AORTA uses reasoning formulas, Lr, with typical 
element p, which are based on organizational formulas, option formulas, belief 
formulas and goal formulas: 

p ::= T I org{(j)) \ opt((/)) | bel(0) | goa\{<p) \ -.p | pi Ap 2 , 
where (j) € L. 

Organizational formulas, org((/)), queries the organizational beliefs, option 
formulas, opt((/)), queries the options base, belief formulas, bel ((/>), queries the 
belief base and goal formulas, goal(0), queries the goal base. 

Definition 5 (Semantics of reasoning formulas). The semantics are based 
on the agent’s mental state, MS = {Ua, Ra, Sdo, To). 

MS \=T 

MS 1= bel((/)) iff (j) € Sa 

MS \= goalifi) iff fi&Ta 

MS 1= orgifi) iff So 

MS \= iff (j)€ To 

MS 1= “ip iff MS ^ p 

MS 1= Pi A p 2 iff MS 1= Pi and MS ^ p 2 

We define the configuration of an agent with an AORTA component as follows: 


Definition 6 (AORTA-agent). An AORTA-agent configuration is defined by 
the following tuple: 

A = (a,MS,AR,F,p), 

where a is the name of the agent, MS is the mental state, AR is the agents rea¬ 
soning rules, AR C TZj^, F is the set of transition functions and p = {pin,Pout) 
is the mailbox, contains incoming and outgoing messages. 

The initial configuration consists of a set of initial beliefs and goals, and the 
organizational specification. The agent has a number of state transition rules 
available, which can be used to change its state. The execution of an entire orga¬ 
nizational cycle will check for messages and external changes, apply obligation 
rules, generate options and execute an action. Then, the reasoning cycle of the 
agent enriched with the component is executed (e.g. the Jason reasoning cycle). 


6 



3 Model Checking Agent Programming Languages 


Much of the work done in the area of model checking MASs and agent pro¬ 
gramming languages has been in the setting of AgentSpeak(L) |5l6l7j . While 
interesting, such approaches are generally hard to extend to other languages 
without a lot of hard work. Furthermore, verification of heterogeneous MASsl^ 
is not possible. Recently, others have proposed a way to verify heterogeneous 
MASs by translating programs into a common metalanguage, meta-APL m- 
However, since this approach requires a translation of the program, we need to 
convince ourselves that the translation is faithful to the original program. 

In this paper, we are focusing on another approach for verifying agent sys¬ 
tems, which is based on an extended version of Java PathFinder (JPF) 
called Agent JPF (AJPF), which takes advantage of the advanced model check¬ 
ing features of JPF, while making it possible to verify properties relevant to 
intelligent agents. AJPF can be used as-is for potentially any APL implemented 
in Java, but its real power shows, when combined with the agent infrastructure 
layer (AIL). AIL is designed so that interpreters of semantically well-defined 
agent programming languages can be implemented using it m, and has been 
optimized for model checking in AJPF, by using techniques such as state-space 
reduction. AIL comes with a simple APL, Gwendolen [10], which provides the 
default semantics for AIL. An AIL agent has a belief base, possibly a rule base, 
goals, plans and intentions. Furthermore, the agent has a reasoning cycle, which 
executes the implementation of the operational semantics. We will not go into 
details with all the different components of AIL, but refer to m for a detailed 
description. 


3.1 Specifying properties 

Model checking agent systems is only useful, if we can specify desirable properties 
in a language that can incorporate the mental attitudes of agents. In AJPF, these 
properties are specified in the property specification language (PSL) [TT]. PSL is 
a linear-time temporal logic (LTL) with additional modal operators for beliefs, 
goals, intentions, actions and percepts. We can thus specify formulas that should 
hold in the system. 

The full PSL syntax is given below, ag is the agent’s name, / is a ground 
first-order atomic formula. 


(j) B{ag, /) | G{ag, /) | A{ag, /) | l{ag, /) | P(/) \ fiV (f \ \ (fUcf \ (fRcf 

B(a 5 ,/) is true if agent ag believes / to be true, G{ag,f) is true if the 
agent has / as a goal. A represents actions, I intentions and P properties of the 
environment. The LTL formulas U and R represents “until” and “release”, re¬ 
spectively. The temporal operators O (eventually) and □ (always) can be derived 
from U and R. 

® That is, MASs comprised of agents implemented in different APLs. 
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The underlying semantics of the modal operators depends on the MAS being 
verified. When using AORTA we can specify the semantics of beliefs as follows: 

MAS h B{agJ) iff MSag h bel(/), 

where MAS is the multi-agent system, and MSag is agent ag's mental state as 
defined in section [5] The semantics of the other modal operators can be given in 
a similar way. 

3.2 AJPF 

Agent JPF is a module for the Java PathFinder [^. JPF consists of an im¬ 
plementation of the Java Virtual Machine (JVM), which can execute all paths 
through a program in order to verify some predefined properties about the pro¬ 
gram. Since the state space often explodes, JPF employs state matching in order 
to reduce the number of states explored. 

AJPF implements a controller, which takes care of execution of each of the 
agents in the system. At each time step, it checks whether the system is in an end 
stat 43 and should terminate, and otherwise it decides which agent to execute. 
This decision is made by a scheduler, which keeps a list of active agents, i.e. 
agents that do not want to sleep. The model checker can then branch out at 
each of these states and execute each of the active agents (by choosing one path, 
executing it until reaching an end state and then backtracking). 

Each agent in an APL (either an AIL-enabled or an existing APL) needs 
to implement the MCAPLLanguageAgent interface, which is used by AJPF to 
perform all the steps necessary for the verification of a system: 

— Perform a reasoning step (MCAPLreasonO). 

— Decide to put the agent to sleep (MCAPLwantstosleepO) or wake it up 
(MCAPLwakeup()). 

— Check if a property holds (MCAPLbelieves (fml), MCAPLhasGoal (fml) , etc.). 

AJPF provides a listener, which is used to verify the properties specified in 
PSL. This can be done by first building a Biichi automaton that represents the 
property, and then compute the global behavior of the system by executing it. 
The product of these, the product automaton, can then be used to check if the 
property is violated. A property is violated if there exists a path to an accepting 
state [8]. The implementation of the model checker in AJPF employs techniques 
that allows progressively building the product automaton |14j , making the veri¬ 
fication process more efficient. 

4 Verification of Organizations in Multi-Agent Systems 

In the previous section, we described the AJPF framework, which can be used 
for verification of MASs. We now turn to verification of organizational MASs. 

An end state is defined as a state where every agent is sleeping and the environment 
is not changing, thus nothing new can happen after such state has been reached. 



In [T^, several desirable properties of organizational MASs were define: what 
makes an organization well-defined, good, effective, etc. These properties re¬ 
quire not only a way to express the beliefs of the agents in the system, but also 
the state of the organization. For example, a good organization “is an organi¬ 
zation such that if the organization has the capability to achieve (j) and there is 
a group of roles in the organization responsible for realizing it, then the roles 
being in charge have a chain of delegation to roles that are played by agents in 
Ai that are actually capable of achieving it ” m- Being able to verify that a sys¬ 
tem satisfies these properties would be a large step towards convincing oneself 
that the system actually works. Verification of organizational aspects has been 
investigated before [nmnEi], but usually only by considering the internals of 
each agent as a black box. Model checking of electronic institutions specihed in 
the ISLANDER framework was explored in m By translating an ISLANDER 
specification into MABLE, a language for automatic verification of MASs, the 
system can be verified using the SPIN model checker. 

The work most similar to ours is described in [^, where a programming 
language for normative MASs is implemented in AIL. Agents in the system can 
interact with an organization, and the system can then verify various properties 
of both the agents and the organization. Our integration with AIL differs in 
that we only verify properties of the agents, but these properties may include 
organizational properties, as defined in the AORTA component. Since AORTA 
is not tightly coupled to a specific APL, the integration with AIL allows us to 
perform verification of existing agents with additional properties concerning an 
organization. 

In the remainder of this section, we show how AORTA can be integrated into 
AIL, such that 1) interpreters implemented in AIL can make use of AORTA, and 
2 ) verification of these systems is possible using ajpeH. 

4.1 Specifying organizational properties 

In order to verify properties about organizational beliefs and options, we need 
to be able to express the properties in PSL. We therefore extend the PSL syntax 
to incorporate such properties: 

tp::=(j)\ Org{ag,f) \ Opt{ag,f) 

The interpretation of Org(ag, /) is given as: 

MAS 1= Org(ag,f) iff MSag h 

where MAS is the multi-agent system (AIL-I-AORTA) and MSag is agent ag’s 
mental state as defined in section [21 Similarly, the interpretation of Opt(ag, f) 
is: 

MAS 1= Opt(ag,f) iff MSag h opt(/)- 

® AORTA and the integration with AIL is open source and is available at 
http://www2.compute.dtu.dk/~ascje/AORTA/ 


9 





In AJPF, we have implemented the extended PSL by adding functions check¬ 
ing whether an agent has organizational beliefs or options to the MCAPLLanguage- 
Agent interface, which defines the methods needed by AJPF to perform model 
checking. 

4.2 Verifying AORTA 

Verification of the agents with an AORTA component requires (1) an integration 
of the AORTA architecture within existing AIL agents, and (2) the ability to 
verify properties about organizational beliefs and organizational options. 

We have integrated the AORTA architecture in AIL, allowing existing in¬ 
terpreters implemented in AIL to take advantage of the AORTA organizational 
reasoning component. The AortaAILAgent extends the AILAgent class as fol¬ 
lows: 

MCAPLreasonCint flag) Executes the AORTA reasoning cycle before calling 
the AIL agent’s own reasoning cycle. 

MCAPLhasOrganizationalBelief (MCAPLFormula phi) Returns true if So con¬ 
tains phi. 

MCAPLhasOrganizationalOption(MCAPLFormula phi) Returns true if IT con¬ 
tains phi. 

wantstosleepO Returns true if both AORTA and the AIL agent wants to sleep. 

AORTA wants to sleep if the last execution did not change anything. 
addBel(...)/addGoal(...)/delBel(...)/removeGoal (...) Responsible for 
synchronization of knowledge bases. 

newMessages (Set<Message> msgs) Checks if any of the incoming messages are 
organizational messages and if so, lets AORTA handle them. Otherwise, they 
are forwarded to the AIL agent. 

We have furthermore implemented an AILBridge, which is responsible for 
updating the AIL agent, when AORTA performs actions that change the belief 
base or goal base. 

5 Evaluation of AIL+ AORTA 

In this section, we evaluate our integration of AORTA in AIL. As we shall see, 
the example is small enough to generate the entire state space within reasonble 
time (takes approximately 10 minutes), so we evaluate the system in two ways: 

1. We generate the product automata on the fly by executing the agent system, 
while verifying each of the properties. 

2. We first generate the entire state space for the system, and use it to verify 
each of the properties. 

The first method is practical for large (possible infinite) systems, or properties 
that can be verified quickly (e.g. that the agents eventually enacts a role, since 
this is the first thing happening in our system). The second method is practical 
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Listing 1. Gwendolen-program for writing a paper. 


GWENDOLEN 
:name: alice 
: Initial Beliefs: 

: Belief Rules: 

: Initial Goals : 
editor [achieve] 

; Plans : 

+!editor [achieve] : {True} <- +editor; 
+!wtitle [achieve] : {True} <- +wtitle; 

+!wabs [achieve] : {True} <- +wabs; 
+!wsectitle [achieve] : {True} <- +wsectitle; 
+!fdv [achieve] : {True} <- +fdv; 

+!wcon [achieve] : {True} <- +wcon; 

+!sv [achieve] : {True} <- +sv; 

:name: bob 
: Initial Beliefs: 

: Belief Rules: 

: Initial Goals : 
writer [achieve] 

; Plans : 

+!writer [achieve] : {True} <- +writer; 

+!wsec [achieve] : {True} <- +wsec; 

+!wref [achieve] : {True} <- +wref ; 


for verifying many properties in a single, finite system, since the time used for 
verification of each property is significantly lower than the time spend generating 
the state space. 

5.1 Example: Writing a paper 

To illustrate the capabilities of the model checker for AIL+AORTA, we use a 
simple example of a group of agents aiming to write a scientific paper using 
an organizational specification to help them collaborate (inspired by [15)1. In 
the example, an editor should create a first draft version (fdv), consisting of 
a title (wtitle) and an abstract (wabs) and the section titles (wsectitle). The 
submission version (sv) is then created by letting a number of writers write the 
sections (wsec) and the references {wref), while the editor writes the conclusion 
(wconc). The writers depend on the editor for the completion of fdv^ while the 
editor depends on the writers for the completion of wsec and wref. 

We consider two agents: Alice, capable of editing the paper and Bob, capable 
of being a writer. We have implemented the agents in Gwendolen. The imple¬ 
mentation of the agents is shown in listing[T] Since the focus is not on verification 
of agents writing a paper, but rather on the organizational coordination mech¬ 
anisms of AORTA, the implementation of each objective is very simple. Note 
that the initial goals of each agent are artificial goals, which are used to generate 
a role enactment option, since AORTA currently only supports generating role 
enactment options based on the agent’s goals. 

The agents are enriched with an AORTA component that enables them to 
enact roles, commit to objectives and coordinate. The AORTA-program for the 
agents is shown in listing [51 The agents are able to delegate goals (the send(R, 
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Listing 2. AORTA-program for writing a paper. 

role (R) : true => enact (R) . 

obj(bel(0)) : bel (me(Me )), org ( obi(Me , _ , bel ( 0 ), _ )) => commit(O). 
send(_, tell, org ( rea(Me , R ))) 

: bel(me(Me), agent(Ag), Ag\ = Me), ~( bel ( sent ( Ag , org ( rea(Me , R ))))) 

=> send(Ag, org ( rea(Me , R ))). 
send(R, achieve, 0) 

: org(rea(Ag, R)), bel(me(Me), Ag\=Me), ~(bel ( sent(Ag , goal(D)))) 

=> send(Ag, goal(D)). 
send (R , tell , 0 ) 

: org(rea(Ag, R)), bel(me(Me), Ag\=Me), ~(bel ( sent(Ag , bel(D)))) 

=> send(Ag, bel(O)). 


achieve, 0) option) and inform about completion of goals (the send(R, tell, 
0) option). They commit to objectives that they are obliged to complete, and 
for simplicity simply enact a role, if it is considered an option. 

5.2 Main results 

Our system was evaluatecH using the properties listed in table [TJ Our results 
are divided into two sets: 1) the on the fly verification, for which we specify the 
number of states explored and the time used, and 2) the complete state space 
verification, in which we only state the time used, since in that case, the number 
of states is constant (the example contains 251 states). 

Properties [Hand [5] check that the agents eventually enacts their roles. Prop¬ 
erty [3] tries to verify that Alice eventually enacts the writer role, but fails, since 
that is not the case. Properties|4]and|5]check that the agents furthermore eventu¬ 
ally knows about the other agent’s enactment. PropertyjHverifies that whenever 
Alice is obliged to achieve wabs, she will eventually believe that she has achieved 
it. Property ini verifies that when Alice believes she has completed fdv, she will 
eventually inform Bob, because of the dependency relation between their roles. 
Finally, property [TT] verifies that the paper is eventually written. Note that the 
time difference between properties |T] and [5] are due to the way the AJPF sched¬ 
uler executes the agents: Bob is only executed once AJPF has detected that 
Alice has nothing more to do. 

Since the time complexity of LTL model checking is exponential in the length 
of the formula [2], we furthermore verified larger formulas to get an assessment 
of the model checker’s capabilities. Property [S] verifies that the agents know 
their own role and the role of the other agent. Property [5] verifies that for every 
obligation it is the case that it is eventually satisfied. Property (TU] verifies that 
all dependency relations are used for generating options, and finally. fT^ verifies 
all of the properties above. 

As expected, once the state space has been fully generated, verification of 
each property is quite fast. We also see that verification of larger formulas takes 
much more time (e.g. property [5] compared to property [7]), which is expected, 

® We evaluated the system using Java 7 on a laptop with a dual core 2.80 GHz Intel 
i7 CPU and 8 GB RAM running Windows 8.1. 
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Table 1. The properties that were verified by AJPF. The results are specified for 1) 
the on the fly verification and 2) the complete state space verification. 



Property 

States^ 

Time^ 

Time^ 

1 

OOrg(alice, rea{alice, editor)) 

6 

0:14 

<10ms 

2 

OOrg(bob, rea{bob, writer)) 

6 

0:26 

<10m.s 

3 

OOrg(alice, rea{alice, writer)) 

11 

0:40 

<10m.s 

4 

OOrg(alice, rea{bob, writer)) 

21 

1:38 

15ms 

5 

OOrg(bob, rea{alice, editor)) 

27 

1:48 

15ms 

6 

JTJ A m A (HI A ID 

31 

2:24 

85ms 

7 

□ (Org(alice, obl{alice, editor, wabs, fdv)) 

251 

8:46 

110ms 


OB(alice, wabs)) 

8 

□ (/\ Org(ag, obl{ag, role, obj, deadline)) 

251 

10:33 

2740ms 

-s- OB(ag, obj)) 


□ (Org(alice, dep[wnter, editor, }dv)) A ti{alice, fdv) 

251 

8:51 

25ms 


—¥ OB{alice, sent(bob, bel{fdv)))) 

10 

□ /\ Org(ag, dep{rolel, role2, obj)) A B(ag, obj) 

OB(ag, bel(obj))) 

251 

9:15 

95ms 

11 

OB(alice, sv) 

167 

8:34 

<10ms 

12 

m A m A A ETJ 

251 

13:10 

15812ms 


since the formulas are LTL formulas. Obviously, generating the entire model 
beforehand is only necessary, when we want to validate several properties, since 
in several of the cases, the entire state space does not need to be explored. 

Our experiments have further shown that one execution of an AORTA cycle 
is on average 10 times slower when executed using JPF compared to executing 
the system on the host JVM (i.e. without running the verification process). 
Even though some decrease in performance is expected, it should be possible 
to improve this by implementing the operational semantics of AORTA using 
AIL. In that case, we have to convince ourselves that the semantics are correctly 
implemented in AIL (i.e., the functionality should correspond to the functionality 
of the existing implementation). Still, the advantage of verifying the existing 
implementation is that the results are directly applicable (i.e., we know that the 
agents will inform each other about their roles, that they will conform with their 
obligations, etc.). 

In section 4, we mentioned that an organization could be considered good if 
the roles are related in such a way that the objectives of the organization will 
be delegated to the agents that can actually achieve them. We cannot directly 
specify general properties like this in PSL, so instead, they must be specified 
using the specific properties relevant to the given system. In our case, we can 
specify this using the dependency relations (property [TOl) and the fact that the 
paper is eventually written (property [TT]). Using the organizational model and 
the agent programs it should be possible to generate such specifications, but 
that is out of scope for this paper. 


6 Conclusion 

As agent systems gain popularity and become increasingly complex, the possi¬ 
bility to understand every part of a system becomes difficult. By model checking 
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agent systems, it will be possible to verify that the agents of the system be¬ 
have as expected and that the outcome is satisfactory. We have discussed some 
of the work done concerning model checking of agent programming languages, 
focusing especially on the generic Agent Java PathFinder, which enables model 
checking of potentially any kind of agent programming language. Furthermore, 
by allowing the implementation of an APL interpreter within AJPF (using the 
Agent Infrastructure Layer), it is possible to optimize the model checking pro¬ 
cess, making it feasible for larger systems. 

In increasingly complex systems, there is often a need for regulation, since 
agents may come from different sources and cannot as such be forced to perform 
actions required to achieve the system objectives. This further creates a need 
for model checking, since the complexity again increases. In this paper, we have 
shown that our framework for organizational reasoning, AORTA, can be model 
checked using an extended version of AJPF. We have integrated AORTA in 
AIL and have verified properties about a system implemented in an APL using 
AORTA for organizational reasoning. We have verified that the agents of the 
system enacts roles, coordinate role enactment and that they can successfully 
delegate tasks using an organizational model describing roles and their relations. 

The AORTA framework is not tightly integrated with AIL, but is rather used 
as a library, which means that many of the optimization techniques of AJPF 
cannot be used. Furthermore, a single step of the AORTA reasoning cycle is 
considered atomic in the current implementation, making it impossible to ver¬ 
ify properties about the internals of AORTA. Even though the system, in its 
current state, makes it possible to verify interesting properties about a system, 
it would be interesting to address these shortcomings in the future. However, 
as we have mentioned, even though the advantages of implementing the opera¬ 
tional semantics of AORTA in AIL rather than using it as a library are desirable, 
they should be weighed against the drawback of not verifying the actual system, 
but a (hopefully) equivalent one (in terms of operational semantics). We believe 
that both approaches have their merits, and an implementation of the oper¬ 
ational semantics in AIL will be also a useful contribution to model checking 
of organization-aware agents. An obvious direction for future work is thus to 
implement the operational semantics in AIL. 

Finally, even though the example used in this paper shows that it is possible 
to verify properties about organization-aware agents, it is rather small and it 
would be interesting to verify larger, more complex systems containing more 
than a handful of agents. 
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